【レポート】Amazon DynamoDB Deep Dive #AWSSummit

みなさま Xin chao. 2019/6/12(水)～14(金) の期間で開催されている、AWS Summit 2019 Tokyo からセッションをレポートします。 このレポートは、「Amazon DynamoDB Deep Dive」です。

概要

Amazon DynamoDBは完全フルマネージド型データストアサービスとして、Amazon.comをはじめ多くのお客様に利用されています。改めてDynamoDBの特徴からどのように利用すると効果的か、データモデリングのテクニックなどより深く知るための情報を紹介します。

スピーカー

アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト 成田 俊 様

レポート

DynamoDB とは

クラウドを利用する大規模サービスの特徴

• 数百万ユーザー以上
• TB, PB, EB
• 世界中
• ミリ秒 / マイクロ秒

この規模を支える DB を開発

Amazon.com では

• Oracle から DynamoDB へ
• 顧客体験の改善
• コスト削減

Amazon DynamoDB

• フルマネージド (メンテフリー, サーバーレス)
• ハイパフォーマンス (無制限のスループット)
• エンタープライズ対応 (暗号化, SLA 提供)

過去21カ月の主要なアップデート

• TTL
• VPC Endpoint
• DAX
• Auto Scaling
• Global Tables
• On-demand backup など

DynamoDB の基礎知識

Table構造

• Table 単位でデータを分割
• Table 内に Item としてデータを保管
• Item 内に Attribute, Attribute は Item ごとに不定
• Partition Key (主キー)
• Sort Key (オプション, Queryによる幅広い探索で利用)
• 完全一致, 範囲探索 など

Item 操作について

• 読み込み
  • GetItem
  • TransactionGetItem
  • Query
  • Scan
• 書き込み
  • PutItem
  • Update
  • TransactWriteItems
  • BatchWriteItem
  • Delete

DynamoDB Transactions

• 複数Item, 複数Table に対する書き込み読み取りで ACID トランザクションが可能に
• 分離レベルは Serializable で ロックは取らない

Partition Keys

• アイテムを一意に識別
• 値をもとにどこに位置するかが決まる
• 内部ではスケールのためにパーティションという単位で分散して保持

Sort Key

• 複合キーとして Item を識別
• パーティション内では ソートキーは昇順で配置
• Partition Key ごとのソートキーの数は制限はなし (LSI がある場合はその制限に合わせる)

Local Secondary Index

• Sort Key 以外に絞り込み検索を行うKey
• Partition Key が同一で 他の attribute で検索のために利用
• 全ての要素 (テーブルとインデックス)の合計サイズを 各 Partition Key ごとに 10GB に制限

LSI 利用例：自分お友達リストの検索用

• Table
  • User(PK), Friend(SK), つながり
• LSI
  • User (OK), つながり (SK), Friend

Global Secondary Index

• Partition Key 属性の代わりとなる
• Partition Key をまたいで検索を行うためのインデックス
• 元のテーブルとキャパシティは別で管理

GSI 利用例：友達リストの検索用

• Table
  • User(PK), Friend(SK), つながり
• GSI マッピング用
  • Friend(PK), User(SK)
• GSI つながりからの検索用
  • つながり (PK), User(SK), Friend

GSI はどのように動作するか

1. Client → Table Update
2. Table → Client Update レスポンス
3. Table → GSI 非同期書き込み

Capacity Control

MySQL での分散方式の例

• 水平分散 : 同一テーブルをあるルールに基づいて 別々の Master に格納
• 垂直分散 : 異なるテーブルをあるルールに基づいて 別々の Master に格納する

必要なスループットをどう安定して実現するか

自分のワークロードにはどのインスタンスがベストか？

Cassandra などの分散 DB による解決

• ノードマスター方式による SPOF のないクラスターアーキテクチャ

分散 DB を例として

• 多くのオペレーションが必要になることも

"You build it, you run it" - Werner Vogels

メンテナンスフリー

• セキュリティ
• 耐久性
• 可用性
• 性能
• 拡張性

→ DBA として多くの知識を身に着ける必要がある, アプリ開発者が DBA となると...

Burst Capacity

• 利用されなかった分を "過去 300 秒" 分までリザーブ
• プロビジョン分を超えたバーストトラフィックを処理するために利用する

Auto Scaling

• ターゲット使用率と 上限, 加減を設定
• 利用は無料
• リクエスト数に応じて自動的に容量を拡大

パーティション内でのスループット

• テーブルスループットは パーティションに均等に付与される
• アクセスされるキーに偏りが発生すると 思うように性能が出ないという状況を招くため PK の設計に注意が必要

負荷が単一パーティションに偏った場合どうなるか

• ある Key に集中すると パーティション割り当て分を使い切ってしまい スロットリングが発生

→ Adaptive Capacity

Adaptive Capacity

• 均等分を超え 余力がある場合 Capacity Unit を 均等から超えて付与する
• 2019年の改善で ディレイがなくなった

DynamoDB on-demand

• 既存テーブルでもどちらを利用するか選択可能、再変更も可能

 

• 様々な機能・改善を実施
• キャパシティの詳細を知りたい方は 2019 年 Santa Clara summit のセッションを参照

データモデリング

データモデリングについて

• RDB とは全く異なる
• NoSQL, DynamoDB の特徴を理解したうえでテーブルを設計する
  • DynamoDB ベストプラクティス
  • Advanced Design Patterns for DynamoDB
  • DynamoDB GSIを使用してクエリのパフォーマンスを向上させ、コストを削減する方法

TENETS OF DYNAMODB DATA MODELING

• ユースケースの理解
• アクセスパターンの理解
• Read/Write ワークロードについて
• Queryの大きさや集計
• Data-modeling
• NoSQLデザインパターン
• Review → Repeat → Review

SQL vs NoSQL design pattern

• SQL : 正規化が重要
• NoSQL : 正規化をしすぎると効率が落ちる, 非正規化も検討

1:1 リレーション or キー・バリュー型

• Partition Key を使ったテーブル または GSI
• GetItem か BatchItem API を使用

1:N リレーション or 親子関係

• Partition Key Sort Key を使った テーブル, GSI
• Query API を使ってアクセス

N:M リレーション

• テーブルと GSI を使用して Partition Key と Sort Key の要素をスイッチして設計
• Query API を用いてアクセス

GSI Overloading

GSI Overloading (GSI の多重定義)

• GSI の制限 : 20/table (制限緩和可能)
• スキーマが異なるデータも Item ごとで保持可能
• 1つの GSI で複数の用途で利用できるように定義 (Overload)

RDMBS の場合

• Table
  • 社員ID (Primary Key), 名前 (Index), 勤務地, 職種

GSI OVERLOADING の例

• Table
  • 社員ID (PK), ColA (SK), Data
• GSI
  • ColA (Partition Key), Data(Sort Key), 社員ID

GSI の利点

• GSI の作成数に関するコスト増加や GSI が検索要件の応じて増えてしまうことを回避

A real World Example

Audible eBook Sync Service の例

 

• DynamoDB でも ER 図までは整備することが重要
• Access Patterns の洗い出しが重要
• Primary Table を設計
• GSI を設計
• Query Conditions を一覧化 (すべての API ごと)

まとめ

• 大規模なユースケースでも小規模な場面でも対応
• Capacity 拡張性や性能面で柔軟に対応
• NoSQL, DynamoDB の特徴を理解したうえでテーブルを設計する
• 構築・運用にかかる時間を削減

感想

DynamoDB を使いこなすには あらためて RDBMS とは異なる発想が必要だと感じましたが、使いこなすだけの価値はあると思いました。